# Authentication and Authorization #

One of the capabilities that can be added to an application by the Service Gateway is *Authentication (AuthN)* with *Azure Active Directory (AAD)* as well as certain levels of *Authorization (AuthZ)*. Using the Service Gateway to apply these capabilities (especially AuthN) makes sense as this is a shared service across the multiple *Roles* exposed by the Gateway. It also relieves each role of the necessity to integrate with (sometimes complex) authentication libraries and frameworks, thus making AuthN integration truly turnkey.

## Authentication ##

Authentication integration in the Gateway is achieved using *Azure Active Directory* as a *Secure Token Service (STS)* and default *Identity Provider (IdP)* which, in turn, is capable of federating with other IdPs to allow user identities from a wide range of systems.

One great advantage of integrating with *AAD* is the capability of *Single Sign-On (SSO)*, such that when a user logs on to a different application eg. Office 365, the same identity will be automatically used when authenticating to the Gateway, thus eliminating repeated credential challenges. 

Cloud identity services rely on identifying not only the user wishing to log on, but also the application that they are attempting to log on to. Identifying the application increases the security of the user's credentials and identity as well as providing a secured channel to reply to a sign-on request with a valid authentication token. Without this knowledge, identity management systems would be vulnerable to various security attacks.

A full description of enabling SSO for single-tenant and multi-tenant applications is provided here: [Adding Sign-On to Your Web Application Using Windows Azure AD](http://msdn.microsoft.com/en-us/library/windowsazure/dn151790.aspx) on MSDN.

### Registering the Gateway for AAD Authentication for Single-Tenant Usage###

As described in the above MSDN article in the section **Register a New Application**, an application may be registered for usage when only users belonging to a single *AAD* tenant will attempt to log on. Following the steps in this section, a new application may be created by a tenant admin specifying **Single Sign-On** as the required access. The App URL and App ID URI values are important:

- The **App URL** value must specify the address of the Gateway, once deployed. This is the address that *AAD* will reply with the authentication token once the user has logged on.
- The **App ID URI** must uniquely identify the application to *AAD*. Generally, the App URL value will work fine here. This is the value that must be specified in the `ApplicationName` configuration attribute.

For single-tenant access, the `Directory` configuration attribute must specify a registered domain name in the directory of the users attempting to log on.

### Registering the Gateway for AAD Authentication for ISV Usage###

*Independent Software Vendors (ISVs)* provide cloud application as *multi-tenanted* applications with more that one customer using the same service or application. *AAD* provides a specific mechanism to enable users from more than one tenancy to sign-on to a single application. The MSDN article [Developing Multi-Tenant Web Applications with Windows Azure AD](http://msdn.microsoft.com/en-us/library/windowsazure/dn151789.aspx) describes this mechanism. 

In the above article, special attention should be paid to the section **Promoting the Application Entry in Windows AD to be Externally Available** which talks about constraints on the **App ID URI** value. When configuring multi-tenanted authentication for the Gateway, the `ApplicationName` configuration value will be the **App ID URI** value as per the single-tenanted configuration, but the `Directory` value no longer refers to the directory of the user attempting to log on, but instead is the directory name of the ISV configuring the Gateway.

In the same MSDN article, the **Add Sign-Up Capabilities to the Application** section describes how tenant administrators for new customers must provide consent to enable the application to log on users for that tenant. This is a one-time administrative process that may be included as part of the provisioning workflow of the application or may be part of manual onboarding instructions.

## Authorization ##

The Gateway provides a light-weight authorization mechanism which enforces the authentication requirements of users to certain parts of roles (identified as URL paths) which allows other parts of a role to allow anonymous access. This is typical of a home or landing page that will present information to users before they log on. Once a user navigates to a path of the application that requires authentication, the standard *AAD* sign-on flow will automatically commence (if they have not already signed on to this or another *AAD* integrated application). The user will be prohibited access to the resource if they do not successfully authenticate.   

